【レポート】ラスベガスで日本語セッションからLearn Fast, Fail Fastの実践を学びました #AWSreInvent #GBL303-JA

お疲れさまです。とーちです。re:Invent2024に参加しています。

この記事では「 GBL303-JA | Learn and be curious: Methods for building a learning developer team(Japanese) 」のセッションレポートをお届けします。

※本記事はセッション登壇者である Masaya Hayashi 様の許諾を得て掲載しております。

セッションの概要

タイトル

GBL303-JA | Learn and be curious: Methods for building a learning developer team [Japanese]

概要

This session is delivered in Japanese. What are the most important things for modern application development? Productivity? Developer experience? While both of those are important, learning is also a key factor. Software development is creative work, and developers should continuously find something new in their work. In this session, learn how to transform your developer team into “learning team” with the help of AWS services.

※日本語訳
このセッションは日本語で行われます。 現代のアプリケーション開発において最も重要なことは何でしょうか？ 生産性でしょうか？ 開発者の経験でしょうか？ いずれも重要な要素ですが、学習も重要な要素です。 ソフトウェア開発は創造的な作業であり、開発者は常に仕事の中で新しい何かを見つけなければなりません。 このセッションでは、AWS サービスを活用して開発者チームを「学習チーム」に変える方法をご紹介します。

スピーカー

Masao Kanamori, Snr Specialist SA, DevAx, Amazon Web Services Japan G.K.
Masaya Hayashi, Chief Technology Officer, SODA inc.

セッションタイプ

Breakout session

概要

前半はAWS Japanの方が登壇、後半はSNKRDUNKというプロダクトを運営するSODA inc. のCTOのMasaya Hayashi様が「グローバル展開」や「デプロイ頻度の低下」というプロダクト開発における課題に対してどのようにアプローチしたかについてお話するセッションでした。このレポートでは後半部分のみお届けします。

プロダクトの概要と課題

SNKRDUNKはユーザ数600万人規模のプロダクトでCtoCのマーケットプレイスを提供しているプラットフォームサービスとのこと。またグローバル展開をしていることも特徴です。

プロダクトが成長し、コードの行数なども増えていく中で以下の課題が出てきたそうです。

• プロダクトのデプロイ頻度が下がってきている
• 日本とグローバルのシステムが分離している

デプロイ回数をちゃんと計測し、プロダクトの指標としてチェックされているのが印象的でした。なおデプロイ頻度が落ちているとのことでしたが、一般的なプロダクトと比べると十分高頻度だと思います。
Findy Team+ Award 2024 も受賞されてるとのことで、開発生産性のスコア計測にはFindy Team+を使っているのかもしれません。

日本とグローバルのシステム分離についてはシステムの分離に伴い組織も分離してしまっていることを課題として挙げられており、これは多くの組織にも当てはまりそうな課題だと思いました。

グローバルプロダクトを見据えたモジュール展開

日本とグローバルのシステム分離という課題に対して、以下のような方針を取ったとのこと

• 現状は一つのECSサービスの上に巨大なモノリスが載っている状態だった
• これをモジュールの単位に分解していく
• 分解したモジュール単位でアプリケーションの日本・グローバル統一化をすることで開発効率をあげていく

上記を行っていく際に課題になったのがどの単位でモジュールを分割していくか？といったところだったといいます。これについてはAWS Japan協力のもと、イベントストーミングでドメイン分析をすることでスピード感を持って進められたとのことでした。

イベントストーミングの進め方については同じSODA inc. 所属の方が書かれていた以下の記事がとても具体的でわかりやすかったです。

https://zenn.dev/team_soda/articles/bc967dd28b400f

イベントストーミングの結果としてコンテキストマップが作成され、それを元にモジュールの分割を行っていったとのことでした。また各モジュールごとに担当チームをローテしながら進めていくことで、各モジュールに対するオーナーシップの意識を高めていく取り組みを実施したそうです。オーナーシップの意識付けは、プロダクトに対するチームの責任感と協力性を高めることも期待できるのでとても良いアプローチですね。

learn fastのためのイテレーション

新しいことを学び実践するイテレーションをどれだけ短くできるかが大事で、そのためにプロに頼ることで最速で学ぶという方法を取ったとのことです。
具体的にはAWS Japanに協力を仰ぐことでイベントストーミングの進行が圧倒的にスムーズになったとのことでした。

しかし、重要なこととして以下のことも話していました。

• AWS Japanの方はイベントストーミング手法だけでなく他社事例にも詳しい
• 一方で、SODA Inc.の組織やプロダクトについては、把握しきれていない部分もある
• そのため、意思決定と実行はあくまでもSODA Inc.側が責任持って行うのが大事：俯瞰して考え自社に最適化していくことが重要

「意思決定と実行はあくまでもSODA Inc.側」という考え方がとても素晴らしいなと思いました。私も外部への依存度が高すぎると意思決定が遅くなる、ユーザーフィードバックへの対応が遅くなる等の理由で、プロダクトの継続的な改善サイクルを回すのは難しいと思っています。

また、学習については、まず課題ありきで、その課題に対して実践するべきことを学習していくといったことも言っていました。
実践（顧客に価値をととげる）すべきことが先でそのための学びとしてとらえるのが重要とのことでした。
このあたりは自分自身の仕事にも同じことが言えるかもと思ったりしました。

fail fastのためのイテレーション

ここでは、作ったものを顧客に届けるイテレーションをどれだけ短くできるかが大事ということを仰っていました。

うまく学べているかどうかを判断するには実践が一番で、一番の実践は顧客につかってもらうこととのことでした。
そのため、全体としては完成していなくても部分的に顧客にリリースする方針を取っており、改善のサイクルを回しているとのことです。

この考え方は、私が担当しているAWSコンサルティング業務とも共通する部分が多いと感じました。プロダクト開発であれコンサルティングであれ、完璧を求めすぎるよりも、まずは価値のある部分をリリースし、実際のフィードバックを基に改善を重ねていく方が効果的だと考えています。こういったアプローチの有効性を、改めて確認できる機会となりました。

まとめ

本セッションを通じて、特に印象的だった点は、以下の2つです。

1. "Learn Fast, Fail Fast"の理念
   • 素早い学習と改善のサイクルを重視する考え方は、現在のプロダクト開発においては必須になりつつあるのかもしれないと感じました。
2. 自社主導の意思決定の重要性
   • プロダクトに関する意思決定と実行の主体は自社にあるべきという考え方です。これは、長くプロダクトを継続させるためには欠かせない考え方だなと感じました。

以上、とーちでした。